<html>
<head>
  <title>Devcathlon</title>
  <link rel="stylesheet" type="text/css" href="../style/boilerplate/chrometheme/chromestyle2.css" />
  
  <script type="text/javascript" src="../style/boilerplate/chromejs/chrome.js">
  /***********************************************
  * Chrome CSS Drop Down Menu- (c) Dynamic Drive DHTML code library (www.dynamicdrive.com)
  * This notice MUST stay intact for legal use
  * Visit Dynamic Drive at http://www.dynamicdrive.com/ for full source code
  ***********************************************/
  </script>
  
  <link rel="stylesheet" type="text/css" href="../style/boilerplate/screen.css" media="screen" />
  <link rel="stylesheet" type="text/css" href="../style/boilerplate/print.css" media="print" />
  <style>
    .body-text {float: left; width : 800px; padding : 10px}
    .style1 {color: #FF0000}
    .style2 {color: #0033CC}
  </style>
</head>

<body>
  <div id="page"> 
    <div id="header">
      <div align="right" style="margin-top: -100px;">
        <img src="../images/logo.jpg">
      </div>
      <div class="chromestyle" id="chromemenu">
        <ul>
          <li><a href="../profiles/browseProfiles.html">Browse Profiles</a></li>
          <li><a href="#" rel="dropmenu1">Matches</a></li>
          <li><a href="../matches/gallery.html">Gallery</a></li>
          <li><a href="#" rel="dropmenu2">Hall of Fame</a></li>
          <li><a href="#" rel="dropmenu3">Help</a></li>
        </ul>
      </div>
  
      <!--1st drop down menu -->                                                   
      <div id="dropmenu1" class="dropmenudiv">
        <a href="../matches/publicMatches.html">Public Matches</a>
      </div>
  
      <!--2nd drop down menu -->                                                
      <div id="dropmenu2" class="dropmenudiv" style="width: 150px;">
        <a href="../hallOfFame/topTeams.html">Top Teams</a>
        <a href="../hallOfFame/hallOfFame.html">Top Individuals</a>
      </div>
  
      <!--3rd drop down menu -->                                                   
      <div id="dropmenu3" class="dropmenudiv" style="width: 150px;">
        <a href="../help/help.html">FAQ</a>
        <a href="../help/contact.html">Contact Info</a>
      </div>
  
      <script type="text/javascript">
  
        cssdropdown.startchrome("chromemenu")
  
      </script>
      <div id="header">
      </div>
  
      <div class="wrapper">
        <div class="body-text">
          <h2>Event Listing</h2>
          <p>The following is a list of all events and event parameters that have been configured
             for use in this Devcathlon installation.<br />
             Please contact your administrator for further information. (INCLUDE ADMIN LINK)<br />
          </p>
          <p>
            <ul>
              <li><a href="#Introduction">Introduction</a></li>
              <li><a href="#Automated_Events">Automated Events</a></li>
              <ul>
                <li><a href="#Commit_early">Commit early (-1 for each 60 minute violation past 120 minutes of file creation)</a></li>
                <li><a href="#Commit_often">Commit often (-1 for each 60 minute violation past 120 minutes of file editing)</a></li>
                <li><a href="#Commit_regularly">Commit regularly (+5 per day)</a></li>
                <li><a href="#Don&#x27;t_wait_until_the_last_minute">Don&#x27;t wait until the last minute (-5 per day)</a></li>
                <li><a href="#Keep_the_repository_clean">Keep the repository clean (-5 per violation, +5 per day if clean</a></li>
                <li><a href="#Keep_the_repository_really_clean">Keep the repository really clean (+5 per day if really clean)</a></li>
                <li><a href="#Perform_QA_locally_before_committing">Perform QA locally before committing (+5 per 60 minutes)</a></li>
                <li><a href="#Keep_the_coverage_high">Keep the coverage high (-1/+1 per change, 10 point bonus at 90%</a></li>
                <li><a href="#Keep_the_coupling_low">Keep the coupling low (-5 at 5.0 and each point after)</a></li>
                <li><a href="#Keep_the_complexity_low">Keep the complexity low (-5 at 5.0 and each point after)</a></li>
                <li><a href="#Collective_ownership">Collective ownership(+10, +5 bonus if 90%</a></li>
                <li><a href="#Provide_Issue_ID_in_commit_messages_(Issue_Driven_Design)">Provide Issue ID in commit messages (Issue Driven Design) (+5 per day, -1 per violation)</a></li>
                <li><a href="#Every_member_has_an_open_issue_(Issue_Driven_Design)">Every member has an open issue (Issue Driven Design) (+5 per day, -1 per violation)</a></li>
                <li><a href="#Don&#x27;t_overload_developers">Don&#x27;t overload developers (-5 per violation)</a></li>
              </ul>
              <li><a href="#Self-reported_Events">Self-reported Events</a></li>
              <ul>
                <li><a href="#Pair_programming">Pair programming (+10 per session per day, 2 max per day)</a></li>
                <li><a href="#Code_review">Code review (+5 per 5 issues found per day)</a></li>
                <li><a href="#Team_meeting">Team meeting (+5 per meeting, 1 max per day) </a></li>
                <li><a href="#Toolsmithing">Toolsmithing (+5, 2 max per match</a></li>
              </ul>
              <li><a href="#Event_Ideas">Event Ideas</a></li>
              <ul>
                <li><a href="#Commit_&quot;right_size&quot;_chunks">Commit &quot;right size&quot; chunks</a></li>
                <li><a href="#Meeting_the_deadline">Meeting the deadline</a></li>
                <li><a href="#Code_reuse">Code reuse</a></li>
                <li><a href="#Documentation">Documentation</a></li>
                <li><a href="#Development_Ratio">Development Ratio</a></li>
                <li><a href="#New_Skills">New Skills</a></li>
                <li><a href="#Recognition">Recognition</a></li>
              </ul>
              <li><a href="#Mock_5_Proposed_Events">Mock 5 Proposed Events</a></li>
              <ul>
                <li><a href="#"></a></li>
                <li><a href="#"></a></li>
                <li><a href="#"></a></li>
              </ul>
            </ul>
          </p>
          <h1><a name="Introduction"/>Introduction</h1>
          <p>The heart of Devcathlon is the &quot;event&quot;, which is an observable and repeatable
             behavior/characteristic of the software process or product along with an algorithm for 
             how the behavior/characteristic will be identified and how points will be awarded based
             upon the observed behavior.
          </p>
          <p>For example, one event might be summarized as &quot;Maintain high coverage&quot;. One 
             possible implementation of this event is a timer-based process that wakes up at the 
             end of each day and checks to see if coverage data has been received.  If so, and if 
             the line-level coverage is above 90%, then the team will be awarded 10 points.
          </p>
          <p>This same &quot;Maintain high coverage&quot; event might also be implemented by 
             monitoring the sensorbase for commit events from a project, and then checking to see 
             if coverage data is available within a short time frame after the commits (such as 1 
             hour).  If so, and if the method-level coverage is above 85%, then the team will be 
             awarded 5 points. </p><p>As this example illustrates, it is possible for the same 
             high-level behavior or characteristic of software development to be implemented in 
             multiple, equally reasonable ways.  For a given match in Devcathlon, the participating 
             teams should be able to decide both the high level behaviors they want observed (such 
             as &quot;maintain high coverage&quot;), as well as the concrete implementation 
             associated with it (&quot;monitor once a day, provide 10 points if over 90% line-level 
             coverage&quot;).  </p><p>The following specifications of events thus begin by 
             summarizing the behavior or characteristic of interest at a high level.  This is 
             followed by one or more concrete implementations, which are known in Devcathlon as 
             &quot;Point Award Rules&quot; (PARs).  PARs are implemented as Java classes that take 
             a Match instance (from which it can determine the teams or individuals involved), a 
             wakeup interval (how frequently to check for the behavior), and zero or more 
             additional parameters.  From this information, it will wake up periodically from the 
             start of the match to the end, assess the behavior and invoke methods on the Match 
             instance to award or deduct points. </p><p>Note that each event includes a 
             &quot;Decay/Incentive&quot; section.  This refers to the desire to design awards such 
             that participants are incentivized to not &quot;specialize&quot; on a single kind of 
             point getting, but to rather attempt to get points in as many different events as 
             possible.  To do this, some events support &quot;decay&quot;, in which the amount of 
             points awarded decreases if the participant has already been awarded points for that 
             event previously. Conversely, an &quot;incentive&quot; is a bonus point award for the 
             first time a team or individual gets a point award for that event.
          </p>
          <h1><a name="Automated_Events"/>Automated Events</h1>
          <p>These events can be automatically monitored via Hackystat sensor data.  Values in 
             <i>italics</i> should be configurable.
          </p>
          <h2><a name="Commit_early"/>Commit early</h2>
          <p><strong>Summary:</strong> Penalize developers for working on new code too long without 
          committing it and thus making it available for others to see and integrate. 
          </p>
          <p><strong>PAR:</strong> Wakeup once every <i>60</i> minutes.  Update the DevTime table 
             for this match with DevEvent sensor data from the past hour.  The DevTime table is a 
             mapping of users to file paths found in the Resource strings of DevEvents to the total 
             DevTime so far for that file path.  Next, update the CommitFile table, which is a 
             mapping of users to file paths found in the Resource strings of Commit sensor data to 
             a timestamp of the last commit associated with that file. </p><p>Now compare the 
             DevTime table to the CommitFile table to determine what &quot;new files&quot; exist. 
             These are files within the project that have DevTime associated with them but no 
             Commits.   
           </p>
           <p>Points are assigned as follows:  <i>0</i> points if a new file is committed before 
              <i>120</i> minutes of DevTime editing has occurred.  <i>-1</i> point for each 
              additional <i>60</i> minutes of DevTime editing before commit. 
           </p>
           <p><strong>Decay/Incentives:</strong> None needed. Commit early is a &quot;one 
              time&quot; point award (per file). </p><p><strong>Rationale:</strong> Penalize 
              developers for negative behaviors, but don&#x27;t reward spurious commits. Note that 
              this event works best in conjunction with events that penalize developers for 
              breaking the build or having low coverage. 
           </p>
           <h2><a name="Commit_often"/>Commit often</h2>
           <p><strong>Summary:</strong> Penalize developers for working on existing code too long 
              without committing their changes and thus making it available for others to see and 
              integrate. </p><p><strong>PAR:</strong> The PAR design for Commit often is almost the 
              same as for Commit early.  The only difference is that the total DevTime computed for 
              a file is reset to zero each time the file is committed.  Thus, the DevTime table 
              shows only the amount of DevTime since the last commit. 
           </p>
           <p>Points are assigned as follows: <i>0</i> points if a changed file is committed before 
              <i>120</i> minutes of DevTime editing has occurred.  <i>-1</i> point for each 
              additional <i>60</i> minutes of DevTime editing before commit. 
           </p>
           <p><strong>Decay/Incentives:</strong> None needed. We don&#x27;t want to hit people 
              harder the first time they get this deduction, nor do we want to make it even more 
              negative. </p><p><strong>Rationale:</strong> The same as for Commit early. 
           </p>
           <h2><a name="Commit_regularly"/>Commit regularly</h2>
           <p><strong>Summary:</strong> Reward teams who work regularly.  </p>
           <p><strong>PAR:</strong>  Wake up <i>once</i> per day during the match.  Check to see 
              that <i>100%</i> of the team members have worked at least <i>60</i> DevTime minutes 
              during the preceding interval, and that <i>50%</i> of the team members have committed 
              at least once during the interval.   If so, then award the team <i>+5</i> points.  
           </p>
           <p><strong>Decay/Incentives:</strong>  We could consider &quot;bonus&quot; points for 
              the first two days of the match in order to incentivize getting started immediately.  
           </p>
           <p><strong>Rationale:</strong> Working regularly on the project is a good thing.  </p>
           <h2><a name="Don&#x27;t_wait_until_the_last_minute"/>Don&#x27;t wait until the last 
             minute</h2>
           <p><strong>Summary:</strong> Penalize teams that work significantly more near the end of 
           a match.  </p>
           <p><strong>PAR:</strong> During the last <i>3</i> days of the match, wakeup once per day 
              and compute the average DevTime, number of builds, and number of commits per day over 
              the entire match thus far.  If any <i>two</i> of DevTime, number of builds, and 
              number of commits exceeds the average by <i>50%</i>, then deduct <i>-5</i> points.  
           </p>
           <p><strong>Decay/Incentives:</strong> None needed.  </p>
           <p><strong>Rationale:</strong>  Schedule your work so that it doesn&#x27;t pile up at 
              the end.  </p>
           <h2><a name="Keep_the_repository_clean"/>Keep the repository clean</h2>
           <p><strong>Summary:</strong> Penalize (or award) developers for committing code that 
              fails (or passes) a continuous integration build. </p><p>This event requires that 
              Build sensor data is generated from the continuous integration server, and that CI 
              build sensor data has a special property associated with it (such as 
              Type=continuous.integration).  This is to distinguish continuous integration Build 
              sensor data from local builds (for which frequent failure is to be expected.)  Note 
              that the specific tag to be checked for could be a configurable property for each 
              match. </p>
           <p><strong>PAR-1:</strong> Wakeup every <i>60</i> minutes.  If there is any CI Build 
              sensor data that does not have a successful Result type, then assign <i>-5</i> points.  
              Note that you get a deduction of a maximum of <i>-5</i> points no matter how many 
              times you fail the build during the interval. </p>
           <p><strong>Rationale:</strong> If you commit code that fails the build, you 
              shouldn&#x27;t be penalized further for any additional commits you make trying to fix 
              the failing build as long as you do them right away (within an hour of the original 
              failing commit).  However, if you wait more than an hour to try to fix it, then you 
              should incur additional penalties. </p>
           <p><strong>PAR-2:</strong> Wake up every <i>1</i> day.  If there are successful CI Build 
              events during that day, then assign <i>+5</i> points. </p>
           <p><strong>Rationale:</strong> Reward developers for passing continuous integration 
              builds. Note that this is relatively easy to &quot;fake&quot;, as there is no 
              verification in the design of this PAR that any actual work was done before kicking 
              off the build. We could look for threshold churn values to ensure that there was 
              nontrivial editing, at least. </p>
           <h2><a name="Keep_the_repository_really_clean"/>Keep the repository really clean</h2>
           <p><strong>Summary:</strong> Award developers for having a CI build that includes extra 
              quality assurance steps beyond compilation.  For example, JUnit, Checkstyle, PMD, or 
              FindBugs. </p><p><strong>PAR:</strong> Wakeup every <i>60</i> minutes.  If there is 
              CI Build sensor data whose results are all passing, then award <i>+5</i> points. </p>
           <p><strong>Rationale:</strong> We want to incentivize teams to implement rigorous CI 
              builds with lots of quality assurance.  The PAR as designed does not validate that 
              extra QA steps are being taken; teams would need to be on the honor system regarding 
              this.  </p>
           <h2><a name="Perform_QA_locally_before_committing"/>Perform QA locally before committing</h2>
           <p><strong>Summary</strong>: Reward developers for running quality assurance tests before committing.  </p>
           <p><strong>PAR</strong>:  Wakeup every <i>60</i> minutes.  If there is Commit sensor data, then check to see if there is JUnit, Checkstyle, PMD, or FindBugs<a href="/p/hackystat-ui-devcathlon/w/edit/FindBugs">?</a> sensor data within five minutes of the commit by that same owner.  If so, award <i>+5</i> points.  </p>
           <p><strong>Rationale:</strong> We do not penalize failure to run QA tests before commits because sometimes a small change does not warrant the checks. Furthermore, if you commit and the build fails, you&#x27;ll get a deduction at that point.  </p>
           <h2><a name="Keep_the_coverage_high"/>Keep the coverage high</h2><p><strong>Summary:</strong> Reward (or penalize) developers who commit code that improves (or degrades) the quality of the test suite.  </p>
           <p><strong>PAR:</strong> Wakeup every <i>60</i> minutes, and see if there has been a CI build event. If so, check to see if there is coverage data available since that CI build event.  If so, compute the <i>line-level</i> coverage and check it against the last available coverage value (if any).  If the coverage is within <i>1%</i> of the previous coverage (or if no previous coverage data is available), do nothing.  If the coverage is over <i>90%</i>, do nothing. Otherwise, award <i>+1</i> (or <i>-1</i>) points, up to a maximum of <i>10</i> points, for each increase (or decrease) in coverage.  Always store the coverage data found on each wakeup for comparison to the next wakeup. </p>
           <p><strong>Decay/Incentives:</strong> Award a one time bonus of <i>10</i> points once the upper threshold of <i>90%</i> is achieved. </p><p><strong>Rationale:</strong> The limit of a 10 point award keeps this in line with other point awards. Having an upper threshold (like 90%) means that once you get over that threshold, falling coverage will not count against you. The incentive award effectively gives you automatic credit for going from 90% to 100% as soon as you cross that theshold. </p>
           <h2><a name="Keep_the_coupling_low"/>Keep the coupling low</h2>
           <p><strong>Summary:</strong> Penalize teams whose code coupling exceeds a threshold.  </p>
           <p><strong>PAR:</strong> Wakeup every <i>1</i> day.  Compute the average coupling (afferent + efferent) per class.  If the average exceeds  <i>5.0</i>, make a one time point deduction of <i>-5</i> points.  Thereafter, make a one time point deduction of <i>-5</i> points each time the average coupling increases by an additional full point. (In other words, deduct another 5 points when the average coupling reaches 6.0, and another if it reaches 7.0, etc. ) </p>
           <p><strong>Decay/Incentives:</strong>  Decay is already built in via the &quot;one time&quot; nature of the deductions.  </p>
           <p><strong>Rationale:</strong> The PAR builds an incentive in to keep the coupling low and to not let it increase significantly.  </p>
           <h2><a name="Keep_the_complexity_low"/>Keep the complexity low</h2><p><strong>Summary:</strong> Penalize developers whose complexity exceeds a threshold. </p>
           <p><strong>PAR:</strong> Same as &quot;Keep the coupling low&quot;. </p>
           <p><strong>Decay/Incentives:</strong>  Same as &quot;Keep the coupling low&quot;. </p>
           <p><strong>Rationale:</strong> Same as &quot;Keep the coupling low&quot;. </p>
           <h2><a name="Collective_ownership"/>Collective ownership</h2>
           <p><strong>Summary:</strong> Reward developers for ensuring that most files are worked on by multiple developers.  </p>
           <p><strong>PAR:</strong> Wake up <i>once a day</i>.  Gather DevEvent data to construct/update a map of all files that are being worked on, which developers have worked on which files, and how much DevTime they have so far contributed to each file.   If a developer has contributed at least <i>1</i> hour of DevTime to a particular file, then their contribution is recognized, otherwise it is not.  Award the team <i>+10</i> points if 50% of all files have been worked on by at least <i>2</i> developers.   </p>
           <p><strong>Decay/Incentives:</strong>  Award <i>5</i> bonus points if <i>90%</i> of all files have been worked on by at least <i>2</i> developers.   Do not award any points for a given day if less than <i>2</i> developers have worked on that day and contributed less than <i>1</i> DevTime hour.  </p>
           <p><strong>Rationale:</strong> Want to encourage developers to work together on files.  However, we do not want to award points when little development effort is being performed on the system. </p>
           <h2><a name="Provide_Issue_ID_in_commit_messages_(Issue_Driven_Design)"/>Provide Issue ID in commit messages (Issue Driven Design)</h2>
           <p><strong>Summary:</strong> A basic practice of Issue Driven Design is that every commit message should reference the Issue that the associated code changes are related to. Penalize developers when they don&#x27;t have a log message with their commits. Reward them when their commit messages include an Issue ID. </p>
           <p><strong>PAR:</strong>  Wake up <i>once</i> per day.  Look at all commit sensor data for the given team.  If there is commit sensor data for the given interval, and if all log messages have a message, and all those messages reference an Issue ID, then award <i>5</i> points.  If there is commit sensor data with no log message, deduct <i>1</i>  point.  </p>
           <p><strong>Decay/Incentives:</strong>  We could have some kind of decay rule that takes effect if a team always references the same Issue ID, indicating that they really aren&#x27;t practicing IDD, they&#x27;re just trying to get the points.  </p>
           <p><strong>Rationale:</strong> Nothing further.  </p>
           <h2><a name="Every_member_has_an_open_issue_(Issue_Driven_Design)"/>Every member has an open issue (Issue Driven Design)</h2>
           <p><strong>Summary:</strong> Reward development teams where each project member has at least one open issue, indicating their current focus of work. </p>
           <p><strong>PAR:</strong> Wake up once per day. Check the current open issues.  If each project member has at least <i>1</i> open issue, then award <i>5</i> points.  If not, deduct <i>-1</i> points.  </p>
           <h2><a name="Don&#x27;t_overload_developers"/>Don&#x27;t overload developers</h2>
           <p><strong>Summary:</strong> Penalize teams where one or more members have too many open issues, indicating there is no clear focus for what they should work on next.  </p>
           <p><strong>PAR:</strong> Wake up once per day. Check the current open issues.  If any project member has more than <i>5</i> open issues, then deduct <i>-5</i> points.  </p>
           <p><strong>Rationale:</strong> It should be possible by looking at the issue list to see what each person should be working on.  There should not be an excessive number of open issues associated with a single developer.   </p>
           <h1><a name="Self-reported_Events"/>Self-reported Events</h1>
           <p>The following are events that Hackystat cannot currently monitor.  Devcathlon must provide some kind of alternative interface for allowing developers to report on these events, as well as some mechanism for verification.  </p>
           <h2><a name="Pair_programming"/>Pair programming</h2><p><strong>Summary:</strong> Reward developers who engage in pair programming.  </p>
           <p><strong>PAR:</strong> After a pair programming session, one of the participating developer can login to a special section associated with the match they are participating in, and record the date, time, and duration of the pair programming session.   The system can then check that there is DevTime for one of the two developers during that interval.  This event instance then gets put on a queue of items to be validated by a member of the opposing team.   If validated, the pair programming session is worth <i>+10</i> points.  </p>
           <p><strong>Decay/Incentives:</strong> No more than <i>2</i> pair programming sessions can be awarded in a single day to a single team. </p>
           <h2><a name="Code_review"/>Code review</h2>
           <p><strong>Summary:</strong> Reward teams doing code review. </p>
           <p><strong>PAR:</strong> After a code review, one of the participating developers logs in to a special section to indicate their participation.  They must indicate (a) how much time each member spent on the review, and (b) how many significant issues each member posted.  They must also indicate the site (such as Google Project Hosting) where the review took place.  This event instance then gets put on a queue of items to be validated by a member of the opposing team.   If validated, the code review is worth <i>+5</i> points for each participating member who found more than <i>5</i> significant issues.  </p>
           <p><strong>Decay/Incentives:</strong> No more than <i>1</i> code review can be awarded in a single day to a single team. </p>
           <h2><a name="Team_meeting"/>Team meeting</h2>
           <p><strong>Summary:</strong> Reward teams for productive face-to-face team meetings.  </p>
           <p><strong>PAR:</strong> After a meeting, one of the participating developers logs in to a special section to indicate their participation.  They must indicate (a) how long the meeting was; (b) how many members attended; and (c) the URL to the Minutes of the meeting.  This event instance then gets put on a queue of items to be validated by a member of the opposing team.   If validated, the meeting is worth <i>+5</i> points. </p><p><strong>Decay/Incentives:</strong> No more than <i>1</i> team meeting can be awarded in a single day to a single team. </p>
           <h2><a name="Toolsmithing"/>Toolsmithing</h2><p><strong>Summary:</strong> Reward developers for creating a generally useful tool or finding a library that saves significant time gets points.  </p>
           <p><strong>PAR:</strong> The developer logs in to a special section to indicate their toolsmithing.  They must  (a) describe the tool they created or the library they found, and (b) provide a URL to the tool. This event instance then gets put on a queue of items to be validated by a member of the opposing team.   If validated, the toolsmithing is worth <i>+5</i> points. </p>
           <p><strong>Decay/Incentives:</strong> No more than <i>2</i> toolsmithing awards can be provided in a single match. </p>
           <h1><a name="Event_Ideas"/>Event Ideas</h1><p>Ideas for events that aren&#x27;t fully worked out yet.  </p>
           <h2><a name="Commit_&quot;right_size&quot;_chunks"/>Commit &quot;right size&quot; chunks</h2>
           <p>Developers should strive for &quot;Goldilocks&quot; commit behavior: not too much code, not too little code.  </p>
           <p>Example point scheme: not sure </p>
           <p>Rationale:  Reward developers when they commit a &quot;reasonable&quot; amount of changes. </p>
           <h2><a name="Meeting_the_deadline"/>Meeting the deadline</h2>
           <p>Getting the project done on time or meeting a particular milestone deserves points.  </p>
           <h2><a name="Code_reuse"/>Code reuse</h2>
           <p>Writing generic code that can be provided as a library.  </p>
           <h2><a name="Documentation"/>Documentation</h2><p><strong>Summary:</strong> Writing documentation is good.  </p>
           <h2><a name="Development_Ratio"/>Development Ratio</h2>
           <p><strong>Summary:</strong> The developer should have at least 1 commit per 1 hour of coding.  </p>
           <h2><a name="New_Skills"/>New Skills</h2>
           <p><strong>Summary:</strong> Points or level advancement for the developer that applies something new i.e., new language or technology.  </p>
           <h2><a name="Recognition"/>Recognition</h2>
           <p><strong>Summary:</strong> The project or code gets noticed by the professional computing community. </p> 
        </pre>
      </div> <!-- body text -->
    </div> <!-- wrapper -->
  </div> <!-- page -->
</body>

</html>